1. Field of the Invention
The present invention relates to a method of running non-native binaries on a host computer system.
2. Background Art
Currently, a large number of differing computer architectures are utilized both commercially and privately. Although many software applications exist for each of these platforms, there are frequent instances in which a desired program will not run on a given computer architecture. This is particularly true for custom applications developed to a specialized task. Binary translation, and in particular dynamic binary translation, are utilized to provide the capability of running non-native code on a host computer system.
Modern OS kernels such as Solaris are fully multithreaded. FIG. 1 provides a schematic illustration of the relationship between light weight processes (LWP). Each user threads 10, 12, 14 are 1-to-1 mapped to light weight process 16, 18, 20. Light weight process 16, 18, 20 are in turn 1-to-1 mapped to kernel threads 22, 24, 26 in the kernel mode. Scheduling and context switching are deployed on kernel threads 22, 24, 26. Dispatcher 28 is utilized to schedule which threads are running at any given time. For this reason, two threads simultaneously calling the same system call (“syscall”) will not block each other and race condition happens only when two threads compete for the same object resources (user data, system resources, etc.).
The standard C library (libc) provides library subroutines such as mutex_lock/mutex_unlock that hide the detail of what each byte in the above data structure means from the common developers. Mutual exclusion locks are data objects that prevents multiple threads from simultaneously executing critical sections of code which access shared data. libraries, such at the standard C library shield developers from having to consider the detailed implementation of mutex locks on a given computer platform. FIG. 2 provides an illustration of the interaction of a mutex lock data structure with a library routine and the kernel. Library routine 30 accesses members of an instance of mutex lock object 32. Kernel 34 also accesses the instance of members of mutex lock object 32 via a system call (syscall).
Dynamic binary translators that are used to translate the library routines written for one platform (e.g. Sparc+Solaris) into code runnable on another platform (x86+Solaris/Linux) must determine what to do when a mutex-related syscall is encountered during execution of the translated code of these library routines. Occurrence of such syscall is probably insinuating the current thread may need to do something to block itself in sleep mode or to wake up other lightweight processes waiting for this mutex to be released, actions yet only doable in the kernel mode. The mutex_lock data structure, if in the native binary, works as a messenger through the syscall interface for the library routines to control the kernel behavior. However, since the kernel OS underneath our translator is of different platform/ISA, it's difficult to just pass the mutex lock directly to the kernel, as it may be viewed in a totally undesirable way. In fact, the common solution for quick translating other syscalls that are not as stringent on the atomicity as the mutex-related ones is to beef up the host data by duplicating/modifying the data structure given by the translated code and pass to the kernel. This is certainly not a choice for mutex-related syscalls requiring atomicity. If kernel views the data structure differently from user, there is a requirement for the translator to prepare new data object for the host syscalls and call them, all completed atomically, which is extremely hard to implement. On the other hand, without kernel help, is seems to be difficult to affect LWPs belonging to other processes.
Accordingly, there is a need for improved methods of executing non-native code on a host computer system.